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Recommendation on Stable IPv6 Interface Identifiers 


Abstract 


This document changes the recommended default Interface Identifier 
(IID) generation scheme for cases where Stateless Address 
Autoconfiguration (SLAAC) is used to generate a stable IPv6 address. 
It recommends using the mechanism specified in RFC 7217 in such 
cases, and recommends against embedding stable link-layer addresses 
in IPv6 IIDs. It formally updates RFC 2464, RFC 2467, RFC 2470, RFC 
2491, RFC 2492, RFC 2497, RFC 2590, RFC 3146, RFC 3572, RFC 4291, REC 
4338, RFC 4391, RFC 5072, and RFC 5121. This document does not 
change any existing recommendations concerning the use of temporary 
addresses as specified in RFC 4941. 


Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc8064. 
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Les 


Introduction 


[RFC4862] specifies Stateless Address Autoconfiguration (SLAAC) for 
IPv6 [RFC2460], which typically results in hosts configuring one or 
more "stable" addresses composed of a network prefix advertised by a 
local router, and an Interface Identifier (IID) [RFC4291] that 
typically embeds a stable link-layer address (e.g., an IEEE LAN MAC 
address). 


In some network technologies and adaptation layers, the use of an IID 
based on a link-layer address may offer some advantages. For 
example, [RFC6282] allows for the compression of IPv6 datagrams over 
IEEE 802.15.4-based networks [RFC4944] when the IID is based on the 
underlying link-layer address. 


The security and privacy implications of embedding a stable link- 
layer address in an IPv6 IID have been known for some time now and 
are discussed in great detail in [RFC7721]. They include: 


o Network-activity correlation 

o Location tracking 

o Address scanning 

o Device-specific vulnerability exploitation 


More generally, the reuse of identifiers that have their own 
semantics or properties across different contexts or scopes can be 
detrimental for security and privacy [NUM-IDS]. In the case of 
traditional stable IPv6 IIDs, some of the security and privacy 
implications are dependent on the properties of the underlying link- 
layer addresses (e.g., whether the link-layer address is ephemeral or 
randomly generated), while other implications (e.g., reduction of the 
entropy of the IID) depend on the algorithm for generating the IID 
itself. In standardized recommendations for stable IPv6 IID 
generation meant to achieve particular security and privacy 
properties, it is necessary to recommend against embedding stable 
link-layer addresses in IPv6 IIDs. 


Furthermore, some popular IPv6 implementations have already deviated 
from the traditional stable IID generation scheme to mitigate the 
aforementioned security and privacy implications [Microsoft]. 


As a result of the aforementioned issues, this document changes the 
recommended default IID generation scheme for generating stable IPv6 
addresses with SLAAC to that specified in [RFC7217] and recommends 
against embedding stable link-layer addresses in IPv6 Interface 
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Identifiers, such that the aforementioned issues are mitigated. That 
is, this document simply replaces the default algorithm that is 
recommended to be employed when generating stable IPv6 IIDs. 


NOTE: 
[RFC4291] defines the "Modified EUI-64 format" for IIDs. 
Appendix A of [RFCA4291] then describes how to transform an IEEE 
EUI-64 identifier, or an IEEE 802 48-bit MAC address from which an 
EUI-64 identifier is derived, into an IID in the Modified EUI-64 
format. 


In a variety of scenarios, addresses that remain stable for the 
lifetime of a host's connection to a single subnet are viewed as 
desirable. For example, stable addresses may be viewed as beneficial 
for network management, event logging, enforcement of access control, 
provision of quality of service, or for server or router interfaces. 
Similarly, stable addresses (as opposed to temporary addresses 
[RFC4941]) allow for long-lived TCP connections and are also usually 
desirable when performing server-like functions (i.e., receiving 
incoming connections). 


The recommendations in this document apply only in cases where 
implementations otherwise would have configured a stable IPv6 IID 
containing a link-layer address. For example, this document does not 
change any existing recommendations concerning the use of temporary 
addresses as specified in [RFC4941] and the recommendations do not 
apply to cases where SLAAC is employed to generate non-stable IPv6 
addresses (e.g., by embedding a link-layer address that is 
periodically randomized); in addition, this document does not 
introduce any new requirements regarding when stable addresses are to 
be configured. Thus, the recommendations in this document simply 
improve the security and privacy properties of stable addresses. 


2. Terminology 
Stable address: 
An address that does not vary over time within the same network 
(as defined in [RFC7721]). 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 
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3. Generation of IPv6 Interface Identifiers with SLAAC 


Nodes SHOULD implement and employ [RFC7217] as the default scheme for 
generating stable IPv6 addresses with SLAAC. A link layer MAY also 
define a mechanism for stable IPv6 address generation that is more 
efficient and does not address the security and privacy 
considerations discussed in Section 1. The choice of whether or not 
to enable the security- and privacy-preserving mechanism SHOULD be 
configurable in such a case. 


By default, nodes SHOULD NOT employ IPv6 address generation schemes 
that embed a stable link-layer address in the IID. In particular, 
this document RECOMMENDS that nodes do not generate stable IIDs with 
the schemes specified in [RFC2464], [RFC2467], [RFC2470], [RFC2491], 
[RFC2492], [RFC2497], [RFC2590], [RFC3146], [RFC3572], [RFC4338], 
[RFC4391], [RFC5072], and [RFC5121]. 


4. Future Work 


At the time of this writing, the mechanisms specified in the 
following documents might require updates to be fully compatible with 
the recommendations in this document: 


o "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based 
Networks" [RFC6282] 


o "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" 
[RFC4944] 


o "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless 
Personal Area Networks (6LoWPANs)" [RFC6775] 


o "Transmission of IPv6 Packets over ITU-T G.9959 Networks" 
[RFC7428] 


Future revisions or updates of these documents should consider the 
issues of privacy and security mentioned in Section 1 and explain any 
design and engineering considerations that lead to the use of stable 
IIDs based on a node's link-layer address. 


5. Security Considerations 


This document recommends against the (default) use of predictable 
Interface Identifiers in IPv6 addresses. It recommends [RFC7217] as 
the default scheme for generating IPv6 stable addresses with SLAAC, 
such that the security and privacy issues of IIDs that embed stable 
link-layer addresses are mitigated. 
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